Skip to content

[draft] ui testing#154

Merged
scottgerring merged 3 commits into
mainfrom
ui-testing
Jan 20, 2026
Merged

[draft] ui testing#154
scottgerring merged 3 commits into
mainfrom
ui-testing

Conversation

@scottgerring

@scottgerring scottgerring commented Jan 19, 2026

Copy link
Copy Markdown
Member

Adds a basic playwright test suite, hooks it up to our compose integration test in github, as well as running after each service completes deploying to AWS on main.

The suite can be run both for compose (mise compose:ui-test) and AWS environments (mise aws:ui-test).

I have also made a small change to user-management to improve its rate limiting.

Test results are annotated onto the actions. Tests that fail and then succeed are annotated as flaky, but the build continues - see e.g. this one here. Playwright tests add about 30s on top of that build; not much when so much time is sunk into the container builds themselves beforehand.

@scottgerring scottgerring force-pushed the ui-testing branch 5 times, most recently from 473be10 to 18d5318 Compare January 20, 2026 10:16
Comment thread .github/workflows/docker-compose-integration.yml
@@ -2,6 +2,7 @@ name: E2E Tests

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This runs the suite after every service completes its AWS deploy. I think this is a bit OTT, but I can't see an easy way of saying "when all the deploys are done", without having one big mega-job that everything is tied into.

Open to suggestions here.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this works, how long do the tests take to run? I assume not very long.

@@ -0,0 +1,158 @@
import { test as base, expect, type Page } from '@playwright/test';

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A fixture to get us into a logged in state

@@ -0,0 +1,209 @@
import { Page, expect, Response } from '@playwright/test';

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Test we can login

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is very cool that you can test the whole OAUth login flow :) Nice work.

@@ -0,0 +1,32 @@
import { test, expect } from '@playwright/test';

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Basic API endpoint tests. \

@@ -0,0 +1,123 @@
import { test, expect } from '@playwright/test';

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The actual "can i login" test

@@ -0,0 +1,40 @@
import { test, expect } from '@playwright/test';

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A stubbed out logout test until #148

@@ -0,0 +1,136 @@
import { test, expect } from '@playwright/test';

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This needs #157 so it can do cleanup afterwards. as long as we are running against dev only, I don't really care (and it produces interesting event traffic!)


builder.Services.AddRateLimiter(options =>
{
// Log when requests are rejected due to rate limiting

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This isn't related, except that I was getting 503s from throttling a bunch with the test suite.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now we are:

  • Rate limiting less aggressively, and per-client
  • Returning a 429 and logging to say what's happened
  • Trying to track client honouring forward-for headers


context.HttpContext.Response.Headers.RetryAfter = retryAfter.ToString();

// Get client IP from X-Forwarded-For (behind LB) or RemoteIpAddress

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We go to lengths to try use forwarded headers for identifying actual client (and not LB)

@scottgerring scottgerring marked this pull request as ready for review January 20, 2026 10:34
Comment thread .github/workflows/docker-compose-integration.yml
@@ -2,6 +2,7 @@ name: E2E Tests

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this works, how long do the tests take to run? I assume not very long.

@@ -0,0 +1,209 @@
import { Page, expect, Response } from '@playwright/test';

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is very cool that you can test the whole OAUth login flow :) Nice work.

readonly backButton: Locator;
readonly shareButton: Locator;

constructor(page: Page) {

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@scottgerring this looks like the kind of thing that would be really really flaky. Relying on data and h1/h2's. Any thoughts on how we prevent that?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so for real flaky, they retry if they flake and flag it on the github UI that it was flaky, but still succeed. they only fail build if the retries fail too.

if you change the UI and break the tests then your build will break like anything else in github (and you can easily check locally - it takes about 8s to run the suite now via mise compose:ui-test).

matching on elements - i think thats just the cost of doing business for this stuff!

@scottgerring scottgerring merged commit fdd9b5d into main Jan 20, 2026
24 checks passed
@scottgerring scottgerring deleted the ui-testing branch January 20, 2026 12:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants